Share one Kit app across test files instead of booting it per file - #6853

Kit-dependence is currently a property of importing a test file: 156 test
modules construct AppLauncher at module scope, so Isaac Sim boots during
pytest collection. Because nothing declares that dependency, tools/conftest.py
has to run every test file in its own subprocess, paying Kit startup once per
file.

Introduce the two pieces needed to change that:

launch_kit() is an idempotent module-scope replacement for AppLauncher. The
first test module in a process boots Kit; later modules receive the running
app, so a pytest run covering several files pays startup once. It raises
rather than silently returning a mismatched app when a file asks for cameras
after a camera-less boot.

The kit / kit_cameras / kitless markers let a file declare which launch
configuration it needs, so files that can share a process can be grouped
without importing them. kit_solo opts a file out of any such grouping.

test_kit_marker_contract.py keeps the markers from drifting: it checks by AST
that a file's declaration matches what it does at module scope. The checks are
AST-based rather than text-based because several kit-free files mention
AppLauncher only in a docstring saying they do not use it. Files are not yet
required to carry a marker; _ENFORCED_ROOTS is empty and grows per package as
files are migrated.

No test file changes behaviour: nothing is marked kit or kitless yet, and no
file calls launch_kit() yet.

The guard found one pre-existing bug on its first run. test_operational_space
assigned pytestmark twice, and the second assignment discarded arm_ci, so the
file had been excluded from the ARM CI lane. Merged into a single list.

Replace the module-scope AppLauncher construction in the Kit-dependent files
under source/isaaclab/test/sim with launch_kit(), and declare the matching
kit or kit_cameras marker on each file.

Because launch_kit() is idempotent, a pytest process covering several of
these files now boots Kit once instead of once per file. Nothing forces them
into one process yet -- tools/conftest.py still runs a subprocess per file --
so this changes how the files launch Kit, not how CI schedules them.

24 files map to `kit` and 4 to `kit_cameras`. The two groups must not share a
process in that order: a camera-enabled app can serve tests that do not need
cameras, but cameras cannot be enabled after startup, so launch_kit() raises
rather than handing back an app that would silently fail to render.

The transform is applied by tools/codemods/kit_launch_migration.py, added
here because ~125 files in other packages remain to migrate. It edits line
ranges in place rather than round-tripping through ast.unparse, which would
discard comments and isort directives, and it preserves each launch call's
position so the Kit-dependent imports below it still run after Kit starts.

The codemod refuses anything it cannot rewrite without changing behaviour,
and reports it. In particular it rejects a conditional launch such as
`AppLauncher(...).app if _USE_KIT else None`, which test_mjcf_converter.py
and test_urdf_converter.py use so they can run kitlessly when the standalone
importer wheel is installed; collapsing that ternary would have made the boot
unconditional. It also refuses a file that references AppLauncher for
anything other than the launch call, since the import is removed.

The per-file runner grants the first camera-enabled test file an extra 700 s
of timeout, because that file compiles RTX shaders (~600 s) on a cold cache.
It identified such files by searching their source for the literal string
"enable_cameras=True".

Migrating a file to launch_kit(cameras=True) removes that literal, so the
buffer stopped being applied and the file was killed at the 120 s startup
deadline instead. That is what happened to
test_simulation_stage_in_memory.py in the kit-reuse-probe-per-file job: it
was reported as a startup hang at 120.94 s having run no tests.

Match the marker and the launch_kit call as well as the old literal, so the
buffer applies both before and after a file is migrated.

Also narrow the probe to the 24 `kit` files and drop the four `kit_cameras`
ones from both sides. The cold shader compile is roughly thirty times the Kit
startup the probe is trying to measure, so including those files tells us
about shader caching rather than about app reuse.

The kit-reuse-probe-batched job surfaced two ways a test file can misbehave
once it no longer has a Kit process to itself.

test_simulation_stage_in_memory.py aborted the interpreter immediately after
collection, with no Python traceback, while the same test passes in its own
process. Creating the stage in memory is sensitive to what else has already
touched the stage or the extension set. The cause is not understood yet, so
mark the file kit_solo to keep it out of any future batching rather than
leave a landmine for whoever wires that up.

test_views_xform_prim.py calls enable_extension() at module scope, so in a
shared process it mutates the running app's extension set during collection,
before any test runs. That is harmless today and the file is not being
changed, but it is the kind of import-time side effect that batching turns
into a cross-file interaction, so say so at the call site.

Neither change affects how these tests run today; both files still get their
own process from tools/conftest.py.

The probe batched the kit_cameras files together with the plain kit ones, on
the assumption that a camera-enabled app is a superset: it can serve tests
that do not need cameras, so booting cameras first would satisfy everyone.

That is wrong, and CI showed exactly where. test_simulation_context.py's
test_headless_mode asserts

    not sim.has_gui and not sim.has_offscreen_render

so it fails in an app that was booted with cameras. The evidence is clean: in
the batch that contained no camera files that test passed 43/43, and in the
batch that booted cameras first it was the single failure out of 462 tests.

So the relationship is not superset but mutual exclusion. Cameras cannot be
enabled after startup, which rules out one order, and some tests require them
to be off, which rules out the other. Treat the two as separate batches.

launch_kit() now raises on any mismatch rather than only when cameras are
requested after a plain boot, so a file can never silently receive an app
configured differently from what its marker declares.

kit_test_files.py takes a --profile and returns one group, which also removes
the cameras-first ordering it previously had to arrange. Both probe jobs ask
for the kit group: it is much the larger, and a camera batch would mostly
measure the one-off ~600 s cold shader compile rather than Kit startup.

The contract test now checks each profile against the markers separately and
asserts the two groups do not overlap, replacing the ordering check that this
change makes meaningless.